@Mattias-Sehlstedt thank you for taking your time to work on this issue!

I do agree that fixing #5077 under no circumstances should introduce #5115. I have extended your PR to try to cover both of these issues. The commit preserves the nullable by wrapping the property's $ref at resolution time: oneOf for OAS 3.1 and nullable:true + allOf for OAS 3.0. The component schema should remain type:object and not be affected.

Due to my experience with tooling tied to OAS I would suggest that the implementation of wrapNullableRef be split into a separate issue and then be implemented as a feat-commit (same as what I suggested here). This since many tools might not handle nullable ref:s at all, and that might lead to people raising even more issue).

There is also the issue that for OAS 3.1., there are many "correct" ways of expressing nullable ref:s. So to better capture this one could preferably have a more semi-formal feat that explained what has been introduced and why (and the basis for the choice of how nullable ref:s are expressed in OAS 3.1).

So the new issue would capture why and how, but it could also ensure that wrapNullableRef is made as a protected method, so that if anyone believes "it should be a type array and not oneOf with a null child", then we could instantly direct them to the option "Then you can override wrapNullableRef with your preferred behavior" (or disable it altogether easily as well). Similar to what was done here to easily give the user the possibility to inject small behavioral changes if they want to.

So we would keep this PR as a simple "prevent accidental leakage of @Nullable for objects introduce in #5018", which would just restore expected and previous behavior. And the real behavior-change is then tracked and explained in isolation and clarity.